Business Analyst Community & Resources | Modern Analyst

BA ABCs: “B” is for BPMN

Howard Podeswa — Sun, 12 Sep 2010 23:21:00 GMT

#2 in the series: “B” is for BPMN
This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “B” – for Business Process Modeling Notation (BPMN). BPMN is the name of a standard often used for modeling business processes. The diagram covered by the standard is called a Business Process Diagram (BPD).

Example:
Figure 1 is a BPMN BPD that describes the process for reserving a room in a private-members club. The process begins when a member requests a reservation for a specified date. A reservations agent determines the rate and then takes one or more of the followings actions:

If the request included a query about basic rooms, the reservations agent checks the availability of basic rooms.
If the request included a query about deluxe rooms, the reservations agent checks the availability of deluxe rooms.
The slash on the flow marked “Query basic rooms” is a default, indicating this flow is selected if none of the conditions are true.

Next, the member selects a room. When the member’s response is received by the reservations agent, one (and only one) of the following actions is taken:

If the member has cancelled, the reservations process is cancelled.
If the member has selected one of the available rooms, then the reservations agent guarantees the reservations and the process ends in success.

Figure 1 - BPD diagram example: Reserve a room in a private-members club

The controversy: Activity diagram or BPD?

Since activity diagrams (the subject of the previous BA ABCs blog) cover the same ground as BPMN BPDs, the question naturally arises, “Which diagram is ‘better’”? In fact, a controversy rages on this issue, with arguments made for and against each approach – so it’s worth exploring. One of the major advantages touted for the UML (the standard that governs activity diagrams) is that by providing a single standard across the lifecycle, translation errors are avoided. By this reasoning, it makes sense to use activity diagrams for both business process modeling and for modeling the logic of the software processes that automate them. On the other hand, the BPMN standard is often seen as the more natural candidate for the specific purpose of modeling business processes. In fact, the commonly accepted best practice is for BAs to use BPMN for this purpose (unless there is a compelling reason to use activity diagrams – such as the use of a UML tool across the project) and to use the UML for its other diagrams – primarily class diagrams. Let’s consider the arguments for and against each option to try to ferret out the truth.

Argument #1: Activity diagrams are technical whereas BPMN BPDs are business-y

Because the UML standard came out of the development world, its diagrams are thought to be code-oriented. But this is more an issue of perception than fact. In truth, the UML is a full-spectrum standard that supports both real-world and technical modeling. While it is certainly the case that there are features of activity diagrams that are technically oriented, the fact is that only a small subset of features should be used by the BA when communicating with business stakeholders – and this subset corresponds closely to commonly understood flowcharting symbols. (The same can also be said for BPMN.) I have a strong suspicion that the word ‘Business’ in the BPMN acronym has had as much impact as anything else in this perception of BPMN’s preferred status for business usage. But when you compare the aspects of the two alternatives that are actually used by the BA, feature by feature, there is in fact little difference between the two, as the next argument explains.

Argument #2: As a whole, BPMN diagrams are easier for business stakeholders to understand than activity diagrams

To get past the rhetoric, let’s compare the modeling elements most useful for BA purposes. Figures 2 and 3 show commonly used BPMN symbols along with their activity diagram counterparts. A quick glance indicates that it is hard to tell the two apart. When you look at these elements side by side you really have to wonder what all the fuss is about. There is one situation, in fact, that is expressed in a clearer manner (from a stakeholder’s perspective) in activity diagrams than on a BPMN BPD: parallel activities. Figure 4 compares the BPD and activity diagram symbols used to indicate two activities that may occur in parallel (meaning that they may occur in any order). I think most people would agree that the BPD symbol – a diamond with an enclosed ‘+’ sign, is much more cryptic than the straightforward parallel lines used for this purpose on activity diagrams.

Figure 2 - BPD flow objects (with UML equivalents)

Figure 3 - BPD connecting objects (with UML equivalents)

Figure 4 - BPD parallel fork (with UML equivalents)

Argument #3: BPMN includes special modeling elements that make it more suitable for business purposes than activity diagrams

Here I do believe there is some merit to the argument in favour of BPMN. One situation not well handled by activity diagrams is the Inclusive-OR. This is the logical construct used to model the common expression ‘and/or’ – as in: Do ‘A’ and/or ‘B’ and/or ‘C’ – depending on various conditions. Figure 5 illustrates the approaches used in the two standards. BPMN BPDs are clearly preferable to the mess of symbols required by activity diagrams. Another situation for which BPMN has a dedicated symbol relates to the handling of events. Figure 6 illustrates the difference between the two standards. BPMN relies on the placement of a circular event symbol to communicate to the reader the timing of a response to an event: an event symbol on an activity means that the event interrupts it whereas an event after an activity means that the activity first is completed and then the event is noted and responded to. Activity diagrams have a fairy simple alternative notation for this – but it may not be as readily obvious to the reader what is being conveyed.

Figure 5 - BPD inclusive gateway (with UML equivalent)

Figure 6 - BPD events (with UML equivalent)

Argument #4: BPMN models B2B interactions better than activity diagrams

In the ‘real world’, businesses interact with other businesses in limited ways, whereas organizational units within a single business have more complex interactions. In BPMN, this is modeled using pools and lanes. A business is represented as a pool and an organizational unit within the business is represented as a lane. Interactions between pools are limited to the passing of messages – effectively mirroring the way that businesses pass requests (messages) to each other while being unaware of each other’s internal processes. Figure 7 illustrates this approach. There is no formalism dedicated to this concept in activity diagrams, though the situation is fairly easily modeled by stipulating that businesses communicate by sending and receiving signals. Nevertheless, signals are not widely used for business process modeling and are less likely to be readily understood than pools by business stakeholders.

Figure 7 - BPMN B2B model using pools

Conclusion
For business process modeling, where all the players are within a single business, there is no compelling argument for either standard. While there are some small advantages to each standard, they tend to cancel each other out. (E.g., while BPMN handles the inclusive-or situation better, activity diagrams model parallel activities more clearly.) However, BPMN does have a clearer approach for modeling B2B interactions.

Final words
This discussion has focused entirely on the BA perspective. A separate set of arguments and comparisons could be made with respect to the suitability of the two alternatives for code generation. But that is a topic beyond the scope of this blog.

Howard Podeswa, author of Noble Inc.
For courses designed by the author in Business Process Modeling, click here: http://www.nobleinc.ca/BA005.html

Why I Don't Use BPMN

Jarett Hailes — Wed, 10 Feb 2010 01:59:00 GMT

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification. I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise. I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations. Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN. One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.”

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.”

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions. The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before. BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines. If there is interaction across the pools then a message flow is used. Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff. With BPMN this is not always readily obvious since all pools continue along their own process flows. I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl. Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily). While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one. To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved.

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes. The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.” BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model.

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready. BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses. Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible. In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use. While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill. When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart. This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components. I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact. Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth. I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process. In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

April 09 Editor’s Note: Should the BA care about BPM and SOA?

Adrian M. — Sun, 05 Apr 2009 21:23:00 GMT

Yep!

OK… this could have been a really short editor’s note but I’ll wait to practice word frugality for my Twitter posts. Yep – you can now follow me and other Modern Analyst editors on twitter: http://twitter.com/ModernAnalyst.

Now back to BPM…

First, I’ll resort to some simple logic:

The backbone of any reputable business is a set of carefully defined business processes which govern how the organization should function (I recommend reading The E-Myth Revisited).
The business analyst role entails understanding how a business organization functions to accomplish its goals (see the business analysis definition in the BABOK 2.0, which has been recently released).
Therefore => BPM is very relevant for the BA! As a matter of fact, BPM should be done by the business analyst.

Business Process Management (BPM) refers to the discipline which business owners and managers employ to think about, understand, and improve upon how a business works in order to accomplish its goals.

This entails:

Business Process – a set of coordinated activities and tasks whose purpose are to accomplish a something of value for the organization.

AND

Management – the practice of (1) planning, (2) organizing, (3) directing, and (4) controlling.

The value of the business analyst is, perhaps, never more apparent then when he/she is involved in planning, organizing, directing, and controlling business processes which aim at enabling the strategic goals of the organization.

In this month’s issue of our eJournal we’ve provided a ton of great content related to business processes and BPM.

A word of caution: while I believe you should master business process management, be careful when and how you apply these skills.

On to SOA…

While many business analysts would be content to stay exclusively focused on the business side of the house, the reality is that, in today’s world, technology is at the core of almost any business initiative. Service Oriented Architecture (SOA) is a system architecture paradigm which is widely used to design and implement the technology behind many process-centric applications.

John Moe’s SOA Column debut has a good introduction to the subject: “SOA What: SOA 101 for Analysts”

If you are a Systems Analyst, then SOA is even more relevant since you may be called upon to design and specify services which will be used as part of a service-oriented type application. We’ll cover more details related to service specifications in future articles.

What are your thoughts on the relevance of BPM & SOA for the BA?

Do you work in an environment where BPM & SOA is used?

- Adrian

Adrian Marchis

Publishing Editor

ModernAnalyst.com